Track Preference: Systems Engineering 

Presentation Title: Re-engineering complex legacy systems at NASA 


Synopsis: 

This presentation will discuss the Lean Project Management and Model Based Systems 
Engineering approach applied to re-engineer the NASA Johnson Space Center, 
Mission Operations Directorate’s flight production process for future space flight 
products. The talk will deliberate on how the approach helped to overcome key 
obstacles and challenges. 


Abstract: 

The Flight Production Process (FPP) Re-engineering project has established a Model- 
Based Systems Engineering (MBSE) methodology and the technological infrastructure 
for the design and development of a reference, product-line architecture as well as an 
integrated workflow model for the Mission Operations System (MOS) for human space 
exploration missions at NASA Johnson Space Center. The design and architectural 
artifacts have been developed based on the expertise and knowledge of numerous 
Subject Matter Experts (SMEs). The technological infrastructure developed by the FPP 
Re-engineering project has enabled the structured collection and integration of this 
knowledge and further provides simulation and analysis capabilities for optimization 
purposes. A key strength of this strategy has been the judicious combination of COTS 
products with custom coding. 

The lean management approach that has led to the success of this project is based on 
having a strong vision for the whole lifecycle of the project and its progress over time, a 
goal-based design and development approach, a small team of highly specialized 
people in areas that are critical to the project, and an interactive approach for infusing 
new technologies into existing processes. This project, which has had a relatively small 
amount of funding, is on the cutting edge with respect to the utilization of model-based 
design and systems engineering. 

An overarching challenge that was overcome by this project was to convince upper 
management of the needs and merits of giving up more conventional design 
methodologies (such as paper-based documents and unwieldy and unstructured flow 
diagrams and schedules) in favor of advanced model-based systems engineering 
approaches. 
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a. Project Description 
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c. Challenges 

1 . Building Project Support 

2. Acceptance of Model Based Systems 
Engineering (MBSE) and Enterprise Architecture 
(EA) as the correct methodologies 

3. Resource Limitations 

4. Maintaining Management Support 

5. Establishing a tool set for MBSE and EA 
development 


Project Description - What is the FPP? 

The Mission Operations Directorate (MOD) supports the crew 
and flight controller training, pre-launch/launch operations, 
and flight operations through a methodology known as the 
Flight Production Process (FPP) 

► This process is a compilation of work tasks conducted by a 
number of technical disciplines within MOD and its operations 
contractor(s) 

► The FPP provides: 

The products required to reconfigure the mission control center 
with its associated training facilities 

The flight software and associated data products required for 
reconfiguring the flight vehicles 

Trained and certified flight personnel, including crew, flight 
controllers and analysts 

The FPP is the set of business processes within the overall 
Mission Operations System (MOS) that are executed for each 
Space Mission 
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What Problem are we trying to solve? 

► The MOD Space Shuttle Program (SSP) and International 
Space Station Program (ISSP) FPP's were not built as one 
integrated system; instead the separate and distinct 
production processes used for these two programs were 
built a piece at a time by each of the six large functional 
areas within MOD: 

Flight Dynamics Division 
Operations Division 
Space Transportation Vehicle Division 
° Expedition Vehicle Division 
EVA, Robotics and Crew System Division 
Mission Operations Facility Division 

Systems Integration was not the basis for the design of 
the Systems established by these Divisions 

► A new FPP is needed for the future and it must be 
efficient if we are to remain competitive 


Challenge # 1 - Building Project Support 

► Establishing that re-engineering our business 
processes was necessary 

MOD management set a clear goal to cut operations costs by 50% 
over FY1 0 Shuttle Program costs by 2014 

The FPP Re-engineering Projects primary objective is to support 
this goal but our vision and corresponding approach was not 
widely understood 

► Building the case that analysis of MODs business 
processes in the context of the FPP will enable the 
development of an MOS that more effectively meets 
user needs 

MODs focus and expertise is on providing world class Mission 
Control Center Operations 

MODs Shuttle and Station Flight Production Processes were not 
established through detailed business process development 

"Systems Engineering" was done on the back end when the 
individual system component designs where fairly mature 


Obstacle # 1 


Convincing our stakeholders that "An 
understanding of the concept of a business 
process and the need to conduct integrated 
business process analysis is a prerequisite for 

systems integration" (1) 


Key Term - Systems_ Integration is an important element in Systems Engineering, it 
involves the integration of hardware, software, products, services, processes and humans. 
The ever increasing scale of complexity of systems and its impact on the business requires 
that we revisit the processes involved in the development and integration of a system" (!) 


What is the scope of MODs System 
Integration problem? 


> The MOD Mission Operations System (MOS) performs 
over 1 50 functions for the Space Shuttle and 
International Space Station Programs 

o These functions are required to Plan, Train and 
Fly all current and future human space flight 
programs 

> These functions result in the production of over 600 
products 








What is the scope of MODs System Integration 
problem? 

Limitations with the Systems Engineering and Integration (SE&I) 
discipline in the 70's and 80's resulting in the usual problems in MODs 
FPP: 

Duplication of functions and associated activities 

Manual data conversion and entry from one tool to the next in the process 
Hundreds of configuration management steps to ensure data integrity 
° Overtime work to get products produced in the available time period 

Interoperability was not addressed in the initial design of these systems and 
had to be addressed after the systems had been developed 

° We had to use a series of process improvement/Lean activities to fix 
problems and streamline the overall process 


Key term - Interoperability is the ability of systems to provide services to and accept services from 
other systems, and to use the services so exchanged to enable them to operate effectively together (1) 
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What Problem are we trying to solve? (Con't) 

Because of limited SE capabilities in the past MOD has not 
been able to effectively develop our P-T-F team business 
processes and then perform analysis of those processes up- 
front in order to perform systems integration 



These two items must be integrated to optimize the cost profile 

• If Facility and User Applications (UA) costs are too low then the 
P-T-F team will need to do extra work to off-set limits in tool 
functionality 

• If P-T-F team needs are not understood up front then Facility and 
UA costs will go up as new functionality requirements are better 
understood 
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Another View of the Problem 


Mission Operations Flight Controllers have system requirements that 
are needed to Plan, Train and Fly Missions 

Facility developers focus is to develop systems/services that meet 
program and security requirements 

Optimally these two viewpoints must be addressed and integrated 
before system design 


Operational & 
Process 
Viewpoint 


Identifies what 
needs to be 
accomplished 
and who does it 



What needs to be done 
How it’s done 
Who does it 

Information required to get it done 




Systems and services that support: 

• Activities 

• Information exchanges 


Systems and 
Services 
Viewpoint 


Relates systems, 
services, and 
characteristics 
to operational 
needs 
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Solving MODs Systems Integration Problem 


► MOD'S business processes (P-T-F team requirements) 
have been captured in a large architecture description 
document 

► Integrating all of them "up front" using this document 
makes it extremely hard to: 

° Understand and integrate the division-to-division 
processes 

° Develop requirements for facility and system design 

You can do integration "on the back end" with multiple 
iterations of Lean type activities to make process 
improvements but this extremely expensive 

MOD needs to develop a more efficient way to develop, 
integrate, analyze and continuously improve a very 
complex architecture 
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Challenge # 2 - Acceptance of 
MBSE and EA 


> Establish that the approach to develop MOD'S 21 st 
century Mission Operations System is to use Model 
Based Systems Engineering technologies to 
establish an Enterprise Architecture 

> Overcome the issues associated with implementing 
a MBSE in an organization with a long history and 
legacy of performing systems integration by hiring 
the right Project Managers 
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Obstable # 2 


"There are groups where MBSE is practiced 
(both within and outside of NASA), but it i 
not widely understood outside of those 

groups" (2) 


Why MBSE? 

► MOD has traditionally used paper based methods 
for developing requirements and designing new 
systems 

► MOD needs a methodology that focuses on 
addressing integration issues up-front in order to 
minimize integration related complexities and 
challenges later on in the system engineering 
process 
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What is MBSE? 

"Model-based systems engineering (MBSE) is the formalized 
application of modeling to support system requirements, 
design, analysis, verification and validation activities 
beginning in the conceptual design phase and continuing 
throughout development and later life cycle phases" (7) 

MBSE enables the systems engineer to precisely capture, 
analyze, and specify the system and its components and 
ensure consistency among various system views. 

For many organizations, AS IS THE CASE FOR MOD this is a 
paradigm shift from traditional document-based and 
acquisition lifecycle model approaches (4) 


Key Terms: A model is an approximation, representation, or idealization of selected 
aspects of the structure, behavior, operation, or other characteristics of a real-world 
process, concept, or system (IEEE 61 0.1 2-1990), i.e. an abstraction. A model usually 
offers different views in order to serve different purposes. A view is a representation of 
system from the perspective of related concerns or issues (IEEE 1 471 -2000). 


Why use MBSE to establish an Enterprise 
Architecture? 


► MOD needs to transform into an agile organization 
to be able to quickly meet needs and opportunities 
that arise in the next decade 

► Currently, most information about how we conduct 
business is housed in different documents, 
spreadsheets, systems and other repositories 

► An EA will allow us to gain a comprehensive, 
integrated, common view of the way we conduct 
business 

The modeling artifacts being developed can easily 
be refined and reused in other applications to 
support product line and evolutionary development 
approaches 
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Why use MBSE to establish an Enterprise 
Architecture ? (Con't) 

► An enterprise architecture will allow us to: 

° Define, develop, validate and execute our missions with a 
common understanding of how our people, processes and 
systems will interact with one another 

° Run models and simulations of our business processes to 
validate our processes and systems and find areas where 
efficiencies can be achieved 

• Improving net-readiness and interoperability 

• Eliminating gaps and overlaps between our operations 
needs and system capabilities 

• Reducing the sustaining costs and 

• Increasing system reliability, robustness and 
maintainability 

The result will be an organization that can quickly assess the 
impact of external events and quickly adapt to changes 
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Challenge # 3 - Resource Limitations 


► The MOD at the JSC is currently providing 
operations for two active programs, the 
Shuttle and Station Programs, with a constant 
focus on flying these missions safely in a cost 
constrained environment 

► With this primary focus it has been 
challenging to find the resources required to 
re-engineer our Business Processes and to 
develop new Systems for future programs 
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Obstacle # 3 A & B 


Because the goals and benefits of our Project, 
and how it supported MODs strategic goals, 
were not broadly understood resources were 

limited 

When choosing the right mix of Process, 
Methods, Tools, and Environment elements, 
one must consider the knowledge, skills and 
abilities (KSA) of the people involved (5) 
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Dealing with Limited Resources 

MBSE can be done with a lean team 

MBSE and EA were not widely understood methodologies 
within MOD at the initiation of this Project 

> As a result the request for support to build a 2 1 st MOS using 
this approach was not readily embraced 

> Without the support of one high level MOD manager 
we would not have stepped into the world of MBSE in 
2008 

> Because of this lack of overall management acceptance 
of the merits of our Project (remember MBSE is 
relatively new) we had to do this work with a lean team 
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Establishing a Lean Team 

We looked for resources that were already moving in 
the right direction 

>MOD had already established a team of SMEs 
across the Divisions who had started the process 
of performing systems integration, in support of 
the CxP, using traditional document based 
methodologies 

Melding this effort into one that utilized our MBSE 
approach was the first step in the process of 
establishing our team 

- Fortunately the leadership for the team 
attempting to perform the paper based SI 
quickly realized the benefits of the MBSE 
approach 
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Establishing a Lean Team (con't) 

We limited the number of employees reporting directly 

to Project Management 

> Only the minimum number of direct reports were co- 
located with the PM 

> A matrix approach was used to establish the rest of 
the team 

° Kept SME's in their home Divisions to allowing 
them to infuse information from a broader group 
of system experts 

° This provided some amount of management 
support as matrix'ed personnel interacted with 
their own management 
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Establishing a Lean Team (con't) 

We consolidated our Key personnel into a core team, 
called the Special Analysis Team (SAT) 

o Representatives from all Divisions (relevant 
disciplines) were included on this team 

o Experienced former flight director led this team 

o Experts in modeling, simulation, design process 
engineering, and systems engineering were also 
included 

o This team developed and established the 
approach for modeling the processes, 
establishing the required tool set and 
performing analysis 

o Subject Matter Experts on this team were 

instrumental in getting buy-in from broader MOD 
team 
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Establishing a Lean Team (con't) 

We took advantage of the "NASA Inter-center 
community of practice model" to build the SAT 

► Allowed us to use available talent across multiple 
centers to reach better technical solutions 

► The team was distributed across several different 
organizations and centers 

• Tietronix - a Houston based contractor 

• Johnson Space Center 

• Jet Propulsion Laboratory 

• Ames Research Center 

Because the SAT was able to quickly embrace and 
understand the MBSE concept teamwork was very 
effective and efficient 
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Challenge # 4 - Maintaining Management 
Support 

► The overarching challenge was to convince 
management that what we were doing was 
necessary and that our cutting edge systems 
engineering methodologies were the right approach 
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Obstacle # 4 


Knowledge of integrated flight production processes 
is not widely understood within the organization 
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Management Support Issues 

► Key people in MOD management positions were 
not convinced of the merits of model based 
systems engineering 

► The Constellation Program that was funding this 
Project was not using a MBSE approach to establish 
the program-wide FPP 

° As a result they were more interested in the final products 
required from the process than the structured design of the 
process itself 

► Each of the project elements (DODAF views, DES 
model, Process Flow Diagrams, etc. ) was foreign to 
MOD management 
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Steps Taken to Obtain Management Support 

We used a Value-Focused Design & Development approach 

► We strived to clearly identify the Project stakeholders 

° Enterprise Level, Flight Projects, System Developers, End- 
Users 

► We then identified what quality attributes were of value 
to each of them? 

° Maintainability, Reliability, Re-usability, Cost-Reduction, 
Performance, Ease of Verification and Validation, 
Analyzability with respect to requirements 

• Mapping table between quality attributes and stakeholders 

► We then targeted the work to deliver these quality 
attributes as effectively as possible 

DODAF viewpoint development, Discrete Event Simulation 
(DES), Management Level Network Executive (MLNE) 
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Value-Focused Design & Development (Con't) 


Quality Attributes of Value for the Project Stakeholders: 



Maintainability 

Reusability 

Risk Reduction 

Cost 

Reduction/Affordability 

Performance 

Analyzability with respect 
to requriements 

Ease of Verification and 
Validation 

Reliability 

Enterprise Stakeholder 

NASA HQ's 


X 

X 

X 

X 

X 


X 

Cx Program 


X 

X 

X 

X 

X 

X 

X 

JSC MOD 

X 

X 

X 

X 

X 

X 

X 

X 

KSC MOD 


X 

X 

X 

X 



X 

Flight Project Stakeholders 

Orion 





X 

X 

X 

X 

Ares 





X 

X 

X 

X 

System Development Stakeholders 

Designers 

X 

X 



X 

X 



Implementers 

X 

X 



X 

X 

X 


Testers 

X 

X 

X 


X 

X 

X 

X 

End-User Stakeholders 

Flight Controller/Mission Analysts 

X 

X 

X 


X 

X 

X 

X 

Flight Directors 

X 

X 

X 

X 

X 

X 

X 

X 

Ground Operations 

X 

X 

X 

X 

X 

X 

X 

X 

Logistics/Maintenance/Recovery and Refurbishment 

X 




X 





The FPP project uses DODAF architectural artifacts (Operations and Systems views), Discrete 
Event Simulation, and the Management Level Network Executive to deliver these values to the 
stakeholders. 
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We mapped Quality Attributes to our 
Modeling Techniques 


Modeling Technique 

Information Flow Spanning 
Organizational Boundaries 
(OV-5, OV-2, OV-3) 

System Capabilities to 
support information flow (SV- 
2,SV-3,SV-6) 

Discrete Event Simulation 

Management Level Network 
Executive 

Quality Attribute 





Cost Reduction 

X 

X 

X 

X 

Risk Reduction 

X 

X 

X 

X 

Maintainability 

X 

X 



Reusability 

X 




Performance 


X 


X 

Analyzability 



X 


Ease of Use 

X 

X 

X 

X 


Steps Taken to Obtain Management Support (don't) 

Project Management established a clear vision for the 
mid and long term state of the project 

► Each of the elements of the project are assessed and 
decisions are made with consideration of the 
expected end state 

► A continuous theme is to always be looking for 
better ways to explain MBSE, DoDAF, etc., in terms 
that non System Engineers can understand 

► Our focus was on understanding Customer needs 
and providing products that meet those needs 

° Develop products that meet customer needs as soon as 
possible - go for quick victories 

Provide value to management throughout the project 
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Challenge # 5 - Establishing a tool 
set to support MBSE and EA 

► Since MBSE and EA were new to MOD we did 
not have a tool set that would support these 
activities 

► As we found out there were many tools that 
would do aspects of what we wanted but 
nothing that would support the end to end 
process integration that we were seeking to 
do 

► We also had a goal of not getting locked into 
a single COTS tool that would prohibit the 
use of other tools 
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Obstacle # 5 


"It will take time before a robust set of tools 
are able to fully support it (MBSE) and it 
becomes a capability of most systems 

engineers " (2) 

"The capabilities and limitations of technology 
must be considered when developing a 
systems engineering development 

environment" (6) 
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Approach - corresponding tree next chart 

Consider the fundamental objectives of the project. 
Decompose it into the means objective 

Determine what technique is used for achieving each means 
objective. 

Determine what class of tools/applications are required for 
the implementation of that technique. 

Determine their corresponding operations concept within the 
context of the modeling and development team. 

► Develop requirements for each class of tool. 

Conduct trade studies to pick the right option within that 
class. 

Take into consideration the Object Management Group (OMG) 
recommendations, (http://www.oma.org/ ) throughout the 

selection process. 
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Objective Hierarchy - FPP Re-engineering 

Fundamental 
Objectives: 

Means 
Objective: 


Reengineer the MOD MOS 
with goal of reducing sustaining costs 


Build an Enterprise Architecture 


Design and Optimize Processes optimize Operations 



Organizational 
Structure (OV-s) 


DES Model 

Completeness; 

Validity; 

Sensitivity Analysis; 



System Structure 
(SV-s) 


Connect 
with program 
models 


Workflow 

Execution 



Risk/Margin 

Management 


Uncertainty 
Management 
by Re-planning 


Interface 

Control Documents 


Design Optimization: 

schedule optimization; queuing systems 

Phased mission systems, 

Trade studies, risk analysis, etc. 
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General Tool Requirements 


> Ease of Data Elicitation from SME’s 

> A focus of Project Management was to provide tools that would allow the 
SMEs to develop and maintain ownership of their Division's processes 

> Maintainability 

> After achieving the primary goal of developing all the Business 
Processes to perform Systems Integration the secondary goal is to 
put in place a tool set that allows the Divisions to maintain and 
easily update their Business Processes 

> Extensibility to a plethora of COTS products. 

We did not want to be locked into any single COTS tool or 
EA framework since the technology is moving so fast and 
there’s significant vendor turnover 
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We had many tools to select from 



/ General 
Purpose 
Simulation 

Mathematica 

imulink 
\ Matlab 


What tool do we use??? 


Discrete 

Event Simulation 

Arena 

SIMPROCESS SIMUL8 

1AI . 4 CORESIM 

Witness 

Rhapsody 
GPSS/H 


Minitab 
Galileo ASSAP 

Hugin _ , . 

Expert Sa P hire 

Statistical/ 
Reliability 
Analysis 


CORE 

Magic Draw 

Rational 
Rose 

Enterprise 
Architect 

Architecture 
Development 
PMN 


System 

Architect 


Process for Model Development 

This process starts with data elicitation from the Subject 
Matter Experts. 

In order to standardize the data representation, an ontology was 
developed based on the Business Process Modeling Notation 
(BPMN) and a glossary of terms and notations for the MOD was 
agreed upon with participation of the SME’s. 

This ontology was then the basis of the data schema underlying a 
customized repository that was developed. 

In order to facilitate the data elicitation process, standardized 
templates were built that allowed SME’s to develop the 
Process Flow Diagrams (PFD’s) for each of the main functions 
that they perform. 

The data in the repository is then transferred into other 
applications for processing. 

Each applications provides a unique type of analysis and processing. 
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Process for Model Development 

► A Visio Add-On has been developed to provide a 
standardized structure for data elicitation from the SME’s. 

The latest data from the repository is available to the SME’s 
automatically in the form of pull-down menus. 

Data from this Add-on is then automatically ingested into the 
repository. 

The repository serves to store and integrate all relevant data. 

The Architecture Views are produced in an Enterprise 
Architecture Application (Currently IBM’s System Architect). 

The Discrete Event Simulation (DES) is performed by a 
specialized DES tool (currently IBM’s Witness). The objective 
of the DES is to simulate, verify and further analyze the 
workflow model. 

The Uncertainty & Risk Analysis is conducted in Galileo ASAP 
and Saphire (NASA PRA tools). 
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How did we do the Modeling? 


SME Inputs 


Workflow Processes 








How did the data flow between applications? 











Why a customized repository? 

MODEAR (Mission Operations Directorate Enterprise Architecture Repository) is a 
repository for the data pertaining to the design of the Mission Operations System. 

Workflow Operations Processes 
° System Architecture 


The totality of the data in MODEAR is available as an XML output and hence MODEAR 
data can be transformed to any arbitrary applications/COTS tools for further 
analysis/processing/development of architectural graphs, etc. 

MODEAR Schema is consistent with the BPMN and DODAF framework and provides a 
reference architecture for Mission Operations System design. 


MODEAR Schema is extensible to additional artifacts for: 

Capturing relevant design information for the system components (Facilities, hw, sw). 

Serving as a database/repository of the performance data during the execution of the workflow 
processes. 

MODEAR has only 70-90k lines of code. This is very insignificant in comparison with 
applications which deal with thousands of kslocs. Building the necessary code to use 
any of the applications for our current purposes would require coding in the same order 
that MODEAR has today. 
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Why did we structure MODEAR 
the way we did? 


► 


► 


In the Data Layer: 

Architecture data elements and their defining attributes, 
relationships, and values 

• Object-oriented data model 

• Relational database schema 
Data retained in MODEAR 

• MySQL 

In the Presentation Layer: 

Products and views that support a visual means to 
communicate and understand the architecture 

• Its purpose 

• Its description 

• The analyses it is expected to support 
Virtual Layer; physically distributed 

• XML is MODEAR’s medium for data exchange among 
the layer’s distributed applications 

- Including client-server messaging 
Currently MODEAR’s Presentation Layer includes: 

• MODEAR User Interface (Ul) 

• System Architect 

- DoDAF Products (OV-2, OV-B, OV-5) 

- Discrete Event Simulations with Witness Plug-in (BPMN) 


Presentation Layer 

Products & Views 

MODEAR 
Browse 
View 


DoDAF 

Product 

View 


Data Layer 

Architecture Elements: Schema + 





MODEAR 
Schema: 
Definitions for 
Entities, 
Attributes, 
Relationships, 
and Constraints 


Architecture 
data values 
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Take-Away’s 


Competent Systems Engineers are typically knowledgeable 
about the various subsystems of the space system, are able 
to see the interfaces, and effectively communicate and 
collaborate with the Subsystem Engineers. 

► Expertise in the formal discipline of Systems Engineering, 
which encompasses modeling and simulation technology and 
uncertainty management is not a requirement for Systems 
Engineers. 

» Both these types of expertise are valuable and necessary in 
today’s market. 

Modeling & Simulation technology is used successfully for 
subsystems (such as rover prototypes and simulations), but 
not at the higher systems level. 
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Take-Aways 

► In a large organization where there are relationships back 
to the home Divisions, with the technical knowledge, we 
found success using a matrixed approach to establish the 
systems Integration team. 

► Take advantage of the NASA Inter-center community of 
practice model that allowed us to use available talent 
across multiple centers to reach better technical solutions 

► Build your team around a few "top guns" to ensure that 
you stay on the leading edge 

► To put in place an MBSE team you need to find people who 
can embrace new ideas quickly (you will need to weed out 
detractors) 

Never stop trying to explain MBSE and its benefits (don't 
make the mistake of thinking others understand what you 
are talking about) 
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Take Away's (don't) 

► Education in and leadership of Model-Based Systems 
Engineering and Information Systems at the Agency 
and, in fact, all levels of management is critical to 
the affordability and sustainment of large, complex 
systems (3) 

► Avoided using a specific COTS tool set to store all 
your data. 

° If all your data is in a COTS tool you will be limited to that 
vendors tool suite for Discrete Event Simulations, developing 
architecture view, etc. 

We developed a custom database designed to provide the 
ability to operate with any XML compatible tool 

Develop products that meet customer needs as soon as 
possible - go for quick victories 
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Take Away's (Con't) 

► Following are the key steps to our success: 

° Clear goals and our ability to stay on target 
° Ability to put together an extremely skilled core 
team 

° Motivated working level personnel who understood 
the Project goals and provided enthusiastic support 
° Project structure and organization 
° The establishment of a powerful tool set that 
facilitated working level personnel support 

° A business atmosphere that mandated cost 
reductions 
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Data Model (ERD) for MODEAR (notional) 
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MODEAR Administration Domain 
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MODEAR 

Entities and Relationships 

► MODEAR Data 
Model is object- 
oriented 

° Entities reflect 
classes 

• Object entity is the 
abstraction 

• Some primary; most 
associative 

• Object_Type maps 
classes to entities 

► Values are seen 
through the lens 
of the MODEAR 
Ul 
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PFD 
Sample PFD 
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PFD 4.1.1 - Assess and Develop Early Mission Timeline (General) 
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PFD 

Sample PFD 

PFD 4.1.1 - Assess and Develop Early Mission Timeline (General) 



PFD 

Sample PFD — Instance 
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More Key Terms (4) 

The word methodology is often erroneously considered synonymous with the 
word process. For purposes of this study, the following definitions from Martin 
[1] are used to distinguish methodology from process, methods, and tools: 

A Process (P) is a logical sequence of tasks performed to achieve a particular 
objective. A process defines “WHAT” is to be done, without specifying “HOW” 
each task is performed. The structure of a process provides several levels of 
aggregation to allow analysis and definition to be done at various levels of 
detail to support different decision-making needs. 

A Method (M) consists of techniques for performing a task, in other words, it 
defines the “HOW” of each task. (In this context, the words “method,” 
“technique,” “practice,” and “procedure” are often used interchangeably.) At 
any level, process tasks are performed using methods. However, each 
method is also a process itself, with a sequence of tasks to be performed for 
that particular method. In other words, the “HOW” at one level of abstraction 
becomes the “WHAT” at the next lower level. 

A Tool (T) is an instrument that, when applied to a particular method, can 
enhance the efficiency of the task; provided it is applied properly and by 
somebody with proper skills and training. The purpose of a tool should be to 
facilitate the accomplishment of the “HOWs.” In a broader sense, a tool 
enhances the “WHAT” and the “HOW.” Most tools used to support systems 
engineering are computer- or software-based, which also known as 
Computer Aided Engineering (CAE) tools. 
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More Key Terms (con't) (4) 

A methodology can be defined as a collection of related processes, methods, 
and tools. A methodology is essentially a “recipe” and can be thought of as 
the application of related processes, methods, and tools to a class of 
problems that all have something in common. 

► Associated with the above definitions for process, methods (and 

methodology), and tools is environment. An Environment (E) consists of the 
surroundings, the external objects, conditions, or factors that influence the 
actions of an object, individual person or group. These conditions can be 
social, cultural, personal, physical, organizational, or functional. The purpose 
of a project environment should be to integrate and support the use of the 
tools and methods used on that project. An environment thus enables (or 
disables) the “WHAT” and the “HOW.” 
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MOS Architecture & DES Development 
Approach 


Integrated with the on-going effort to develop the overall MOP Mission 
Operations Architecture Description Document (MO ADD). 

The Baseline Operations Plan (BOP) and Flight Preparation Process (FPP) development 
efforts have combined with a common focus of creating a MO ADD 

MO ADD data is being used by the Special Analysis Team (SAT) to create the MOS 
Model 

Use Department of Defense Architecture Framework (DoDAF 1 .5) as the 
standard for identification all the activities and associated processes. 

Selected DoDAF views utilized are based on project objectives. 

MOS Model Maturation Process is tied to the MOP Development Lifecycle: 

Recursive Decomposition Process: The highly related nature of the products 
necessitate that tney be developed in an iterative manner, as greater understanding is 
achieved of work processes. 

Today MODEAR produces: 

• Functional Flow Block Diagrams (DoDAF Activity Model, OV-5) 

• Process maps (PFDs, precursor of DoDAF Operational Event/Trace, OV-6c) 

• Needlines (DoDAF Operational Node Connectivity, OV-2) 

• Product Exchange - Functional Dependency (precursor of DoDAF Operational 
Information Exchange, OV-3) 

Build Discrete Event Simulations (DES’s) in alignment with the development 
lifecycle: 

Prototype DES (Completed) 

Functional DES (Completed) 

Operational View DES (On-going) 

System View DES (Future) 

Note: Process modeling per Business Process Modeling Notation (BPMN) 


59 


Summary - Model Based Systems Engineering 


Why you don’t want to model (common objections) 

• Modeling is hard 

• Modeling tools are difficult 

• Modeling will likely require cultural changes 

° Why you dfi want to model 

• It increases the rate of communications 

• It increases the precision of communications 

• It promotes a common understanding of your Processes 
and the Systems that support those Processes 

• It enables validation of the design. 

• It enables simulation , optimization and execution of 
design. 
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